World Wide Web registration information processing system

ABSTRACT

A World Wide Web registration processing system is disclosed for assisting World Wide Web users in registering at World Wide Web web sites. For each such user, the registration processing system includes a long term repository for the user&#39;s web site registration information so that this information can be automatically transferred to a plurality of web sites to which the user may at time to time request to be registered. Further, the registration processing system provides the user with the capability to have a common user identification that may be used for accessing services at a plurality of web sites.

RELATED APPLICATION

This application claims priority from a provisional application filedDec. 11, 1995, entitled "A WORLD WIDE WEB REGISTRATION INFORMATIONPROCESSING SYSTEM" and assigned provisional Ser. No. 60/008,736.

FIELD OF THE INVENTION

The present invention relates to a system for assisting World Wide Webusers in registering at World Wide Web web sites. In particular, thepresent invention provides storage and access to web site registrationinformation provided by a user of the present invention so that, uponrequesting to register at a web site that cooperates with the presentinvention, the user can request his/her web site registrationinformation stored by the present invention to be transmitted to thecooperating web site.

BACKGROUND OF THE INVENTION

The World Wide Web (WWW) is a global communications network having aclient-server model as a paradigm for communications. That is, users onclient nodes utilizing so called "web browsers" navigate the WWW toaccess desired server nodes (known as web sites) for at least obtaininginformation from the server nodes such as hypertext, audio, video,virtual reality, data, etc. For many web sites, it is important to thoseresponsible for the design and maintenance of the web sites that they becapable of accurately measuring both the number and types of usersaccessing their web sites. In particular, such measurements may beimportant in determining fees that can be charged by web site developersfor building and maintaining a web site. Further, such information maybe useful in determining the degree of interest in services and productsby web site users. Thus, in order to obtain these web site measurements,such web sites have begun requesting that each user provide informationabout himself/herself prior to the web site allowing access to web siteservices. That is, such web sites require a user to "register" at theweb site, wherein the user is required to establish a useridentification (user ID) and optionally a password with the web site aswell as typically provide personal information such as, for example, thecity of residence or family size. However, registering at multiple websites is burdensome for users in that it is: (a) time consuming, and (b)the user is likely to have different user IDs at different web sites,thus requiring a user to maintain a list of user IDs (and optionallypasswords) for the web sites to which he/she is registered.

Therefore, it would be advantageous to alleviate many of the abovedifficulties by automating the registration process at web sites so thatusers may register at a single web site and use the information providedat this web site to more easily register at other web sites.

SUMMARY OF THE INVENTION

The present invention is a registration information processing systemfor the World Wide Web that substantially automates the userregistration process at web sites. The registration system of thepresent invention includes a World Wide Web registration web sitewherein a user accessing the World Wide Web can utilize this web site asa repository for registration information so that the user can requestthis registration information to be transmitted substantiallyautomatically to another web site to which the user desires to register.Furthermore, the present invention provides the user with a common userID, and optionally common password, that can be used to access aplurality of web sites so that there are fewer web site user IDs andpasswords for the user to remember. Additionally, the present inventionmay establish the common user ID (and optionally password) through userinput such that the user may request a candidate user ID (and optionallypassword) and, if acceptable, the candidate user ID becomes the commonuser ID. However, if the candidate user ID is unacceptable (e.g.,because it is a duplicate of another user's common user ID), then thepresent invention provides the user with one or more alternatives forthe common user ID (and optionally password) that the user may accept orreject. Further, note that whenever possible the present inventionprovides the user with alternative common user IDs wherein thealternatives are derived from the candidate user ID provided by theuser.

The registration information processing system of the present inventionhas a first embodiment using a first system architecture wherein a userneed not have any modules specific to the present invention loaded onhis/her World Wide Web client node. In this embodiment, once the userhas provided registration information to the registration web site ofthe present invention, when the user subsequently requests to registerat a new web site cooperating with the registration process of thepresent invention, then the user provides this new web site with a userID and optionally password (e.g., the above-mentioned common user ID)for the registration web site of the present invention together with anindication that any further information may be obtained from theregistration web site. The new web site subsequently is able toautomatically retrieve the user's registration information from theregistration web site and register the user at the new web site.

In a second embodiment of the present invention having a secondarchitecture, World Wide Web client nodes have registration modules forthe present invention loaded on them so that these nodes may interactwith the registration web site for providing user registrationinformation to cooperating web sites to which the user requests toregister. In this second embodiment of the present invention, the user'sregistration information is stored both locally on the user's clientnode and at the registration web site, the web site being used as abackup. Thus, when the user desires to register at a new web site, theuser's registration information is provided to the web site from theregistration module residing on the user's client node.

In either embodiment, the present invention may also provide a "mass"registration capability, wherein a user may request that the presentinvention automatically register the user at a plurality of web sites.For example, the user may be provided with a capability to search forweb sites cooperating with the present invention by, for example,category and request an automatic registration at multiple web sitessubstantially simultaneously.

Other features and benefits of the present invention will becomeapparent from the detailed description with the accompanying figurescontained hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of the web site registration informationprocessing system of the present invention, wherein this system is shownin the context of its connections to various nodes of the World WideWeb;

FIGS. 2A and 2B provide a flowchart for describing the steps performedwhen a user of the World Wide Web explicitly contacts the registrar website 100 of the present invention for supplying registration informationto be used in registering at third party web sites 116;

FIG. 3 is a flowchart presenting the steps a user of the World Wide Webperforms when entering web site registration information into fill-outforms that are to be submitted to the registrar web site 100 of thepresent invention;

FIGS. 4A and 4B present a flowchart for the steps performed when a userof the World Wide Web accesses a third party web site 116, cooperatingwith the present invention, and in the process of registering at thethird party web site the user is automatically put in contact with theregistrar web site 100 of the present invention so that registrationinformation may be provided to the present invention for registering theuser at the present third party web site as well as other third partyweb sites that the user may subsequently request;

FIG. 5 is a flowchart of the steps performed by the present inventionwhen transferring user registration information from the registrar website 100 to a third party web site 116 to which the user has requestedto register;

FIGS. 6A and 6B provide a flowchart of the steps performed whensupplying a third party web site 116 with registration information fromthe registrar web site 100, assuming that the third party web site hasrequested such information and that the request has been authenticatedat the registrar web site 100;

FIG. 7 presents a flowchart of the steps performed by the presentinvention when supplying a third party web site 116 with userregistration information from the user registration information database144;

FIG. 8 presents a flowchart of the steps performed when storing in theuser registration information database 144 a user's ID (and optionallypassword) relating to a third party web site 116 to which the user isregistered via using the present invention;

FIG. 9 is a flowchart of the steps performed when registering at a thirdparty web site 116 using the module 156 of the present inventioninstalled on the user's client node 108;

FIG. 10 is a flowchart of the steps performed when the registrationmodule 156 on the user's client node is utilized in supplying a thirdparty web site 116 with registration information;

FIGS. 11A and 11B present a flowchart of the steps performed when aWorld Wide Web user of the present invention changes his/herregistration information stored in the present invention;

FIGS. 12A and 12B present a flowchart of the steps performed when thearchitecture of the present invention includes the registration module156 provided at the user's client node 108 and the user requests toenter registration information into the present invention using thismodule; and

FIGS. 13A and 13B provide a flowchart of the steps performed when aWorld Wide Web user requests a user ID for the registration informationprocessing system of the present invention and the present inventionincludes module 156 on the user's client node 108.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of a web site registration informationprocessing system of the present invention, (hereinafter also denoted bythe name "registrar") wherein this system is shown in the context of itsconnections to various nodes of the World Wide Web (WWW). In a firstembodiment, a web site, denoted the registrar web site 100, provided bythe present invention, is connected to the World Wide Web 104 forcommunicating with both World Wide Web client nodes such as WWW clientnode 108, and with other web sites such as third party web site 116,wherein the registrar web site 100 facilitates the registration of auser at a WWW client node 108 when this user desires to register at thethird party web site 116. In this first embodiment, the user accessesthe World Wide Web 104 through a WWW browser 120 on a WWW client node108 wherein, to use the registration facilities of the registrar website 100 for registering the user at a one or more third party web sites116, the user must in some manner request explicit access to theregistrar web site 100 for registering his/her registration informationto the registrar web site 100. Additionally, in this first embodiment ofthe present invention, the WWW client node 108 need not have executableprogram modules designed specifically for interfacing with the registrarweb site 100. That is, substantially any conventional World Wide Webbrowser may be used as the WWW browser 120.

Thus, the first embodiment of the present invention may be described asfollows. In order for a user to register at one or more third party websites 116, the user at a WWW client node 108 accesses the World Wide Web104 and in a first scenario explicitly navigates through the World WideWeb 104 to the registrar web site 100 wherein a registrar web site 100home page is communicated back to the user's WWW browser 120. As oneskilled in the art will appreciate, program modules 128 (hereinafterdenoted "registrar applications") output, to a World Wide Web networkserver 132, information in, for example, a hypertext markup language(HTML) related to capabilities of the registrar web site 100 inassisting the user in registering at third party web sites 116. Suchoutputs from registrar applications 128, are subsequently transmitted,via the network server 132 and the network interface 136, to the user'sWWW browser 120 in the hypertext transfer protocol (HTTP), as oneskilled in the art will appreciate. Thus, upon presentation of theregistrar web site 100 home page on the user's WWW client node 108, theuser subsequently may request to provide registration information to theregistrar web site 100 so that he/she can have this information at theregistrar web site 100 automatically transferred to a third party website 116 when the user is requested to register at such a third partyweb site. Subsequently, after the user's request to supply registrationinformation is transmitted to the registrar web site 100 (via World WideWeb 104, network interface 136 and network server 132), the registrarapplications 128 receive the request and output to the user's WWWbrowser 120 one or more "web pages" having fill-out forms to bepresented to the user via the WWW browser 120. Thus, upon submittal ofthe filled out forms by the user to the registrar web site 100 (moreprecisely, the registrar applications 128), the user's registrationinformation is stored in the user registration information database 144.

Following the above registration procedure at the registrar web site100, the user may then substantially automatically register at variousthird party web sites 116 that are affiliated with the registrar website 100 in that an agreement has been reached between each such thirdparty web site 116 and the registrar web site 120 for transmitting auser's registration information to the third party web site 116 when,for example, the user requests such transmittal. Thus, assuming the useraccesses the third party web site 116 and, for example, the home pagefor the third party web site 116 includes a form field allowing the userto specify that the user's registration information is stored andaccessible at the registrar web site 100, then the user can submit aresponse, via the World Wide Web 104, to the third party web site 116indicating that the user's registration information should be obtainedfrom the registrar web site 100. Thus, the third party web site 116requests and receives the user's registration information from theregistrar web site 100 and stores the user's registration information inregistration information database 148 directly accessible by the thirdparty web site 116. Additionally note that when the registrar web site100 receives a request from the third party web site 116 for userregistration information, a registrar application 128 records therequest for the user's registration information in a registrar accesslog data base 152. Thus, the registrar web site 100 maintains a log ofthe third party web sites requesting registration information. Further,such third party web sites 116 may periodically provide the registrarweb site 100 with information related to the frequency that usersregistered at the registrar web site 100 have accessed the third partyweb sites 116. Therefore, by also storing this information, for example,in the registrar access log 152, the registrar web site 100 is able todetermine the frequency and type of access of third party web sites 116by users.

In a second method of using the first embodiment of the presentinvention, instead of the user explicitly navigating the World Wide Web104 to the registrar web site 100 for providing registrationinformation, the user may instead access a third party web site 116wherein the home page or registration page for the third party web siteincludes input fields allowing the user to request that the registrarweb site 100 automatically be accessed so that the user can enter website registration information at the registrar web site 100 andsubsequently use the registration information provided to the registrarweb site 100 for automatically registering at the third party web site116 (as well as other third party web sites that may be subsequentlyrequested). That is, the newly entered registration information istransferred to the third party web site 116 by entering into a registrarspecific portion of the registration form for the third party web site116 a registrar user identification and optionally a password forrequesting that the third party web site access the registrar web site100 to obtain the user's registration information. Thus, the user'sregistration information automatically is communicated to the thirdparty web site 116 without the user explicitly having to navigate theWorld Wide Web 104 and access the registrar web site 100 to registerhis/her web site registration information.

Note that alternative embodiments are within the scope of the presentinvention, wherein program modules for the present invention aredistributed so that there is an executable module provided on the user'sWWW client node 108 for communication with the registrar web site 100 aswell as with third party web sites 116 that accept registrationinformation from the present invention. In one embodiment of such adistributed architecture for the present invention, a registrarregistration module 156 is integrated into the user's WWW browser 120for gathering the user's web site registration information andcommunicating with the registrar web site 100 as well as cooperatingthird party web sites 116 at which the user desires to register. Such aregistration module 156 may provide the user with easier access tohis/her registration information since the information resides locallyon the user's WWW client node 108 in a persistent nonvolatile storage.Further, the registrar registration module 156 may be activated forentering or updating user registration information without the usernecessarily being connected to the World Wide Web 104. Moreover, byintegrating the registrar registration module 156 into the user's WWWbrowser 120, the user is presented with an integrated set of functionsfor registering and accessing third party web sites 116.

Thus, in such distributed architectures, after the user has enteredregistration information into the registrar registration module 156,this module will substantially automatically contact the registrar website 100 (via the World Wide Web 104) and thereby communicate the user'sregistration information to the registrar web site 100 so that, forexample, the user's registration information may be reliably stored incase there are failures at the user's WWW client node 108. Thus, toaccess a third party web site 116 that cooperates with the registrar forregistering the user, once the user has made contact through the WorldWide Web 104 with such a third party web site 116, the user transfershis/her registration information from the registration module 156 to thethird party web site. Further note that in the registration process ofthe present embodiment, whenever the user registers at a third party website 116, the registrar web site 100 is provided, by (for example) themodule 156, with information related to the registration so that theuser also has a off-site backup copy of all registrations at third partyweb sites residing at the registrar web site 100.

Note that other distributed architectures for the present invention arealso contemplated wherein the registrar registration module 156 on theuser's WWW client node 108 is not integrated with the user's WWW browser120. In such an embodiment, the user may be faced with a different userinteraction technique for the module 156 than that of the WWW browser120. However, the user is provided with added flexibility in choosing aWWW browser 120 and/or using his/her existing browser 120 which may notcontain as part of the browser the registrar registration module 156.

In FIGS. 2A and 2B, a flowchart is presented describing the stepsperformed when the user explicitly navigates the World Wide Web 104 tocontact the registrar web site 100 for supplying registrationinformation. Accordingly, assuming the user contacts the registrar website 100, in step 204 the web site 100 receives the user's request forinformation. Subsequently, in step 208 the registrar web site 100responds with a home page describing the registrar services, a selectionor browsing capability for reviewing third party web sites 116 acceptingregistrar registrations, and a fill-out form so that the user mayrequest to proceed, if desired, with entering registration informationat the registrar web site 100. In step 212 the user determines whetherto proceed with the registration process or not. Assuming the userelects to proceed, the request to proceed is transferred back to theregistrar web site 100 wherein a registrar application 128 examines theresponse and outputs a fill-out form that is transmitted back to theuser's WWW browser 120 so that the user may enter his/her registrationinformation and submit it to the registrar web site 100. Thus, in step216 the steps of the flowchart of FIG. 3 are performed by the user whenentering information into the registration fill-out form provided by theregistrar web site 100. Subsequently, in step 220 the user initiates thetransfer of his/her registration information to the registrar web site100. Note that the submittal of the registration information may beperformed by a conventional electronic transfer through the World WideWeb 104 using any one of various internet protocols or, alternatively,other techniques for transferring the information to the registrar website 100 are also contemplated. For example, the user may fax a printedcopy of a completed registration form to the registrar web site 100 atwhich point the information may be manually input into the userregistration information database 144. In step 224, upon receiving theuser's registration information, one or more registrar applications 128review the user's registration information for determining whether thereis enough information supplied to at least uniquely identify the user.If not, then in steps 228 and 232 a registrar application(s) 128requests additional information from the user and flags the user'sinformation currently stored in the user registration informationdatabase 144 indicating that a user response is required to furtherprocess the user's information. As an aside, note that other feedbackloops to the user are contemplated that are related to the loop of steps224 through 232. For example, it may be the case that the user hassupplied sufficient information to be uniquely identifiable at theregistrar web site 100, but the user has supplied insufficientinformation for the registrar web site 100 to supply adequateinformation to most third party web sites 116 that utilize registrarregistration capabilities. Thus, a similar feedback loop to loop 224through 232 may be provided for requesting that the user supplyadditional information so that a substantial number of third party websites 116 cooperative with registrar will allow the user to register atthem using only the information supplied by the registrar web site 100.

Referring again to step 224, if a determination is made that sufficientregistration information has been received at the registrar web site100, the user's registration information is stored in the userregistration information database 144 (step 236) and subsequently aregistrar application 128 outputs a request to the user to select a userID and password that can be at least used to access the user'sregistration information at the registrar web site 100 (step 240).Assuming, as in step 244, that the user submits a user ID and a passwordto the registrar web site 100, then in step 248 a determination is madeby the present invention (more particularly, a registrar application128) as to whether the user supplied ID and password is acceptable foruniquely identifying the user. If not, then steps 240 through 248 arerepeated until an appropriate user ID and password are entered by theuser. Thus, assuming that an acceptable user ID and password areprovided, in step 252 the registration information supplied by the useris marked as unverified since there has been no independent confirmationthat the user supplied information is accurate. Subsequently, in step256 a registrar application 128 commences to enrich the user's suppliedregistration information with publicly available information related tothe user and, to the degree possible (i.e., conforming with internetetiquette, privacy concerns of users, and public policy), to verify theuser's registration information. Note that by comparing the usersupplied information with information about the user from other sources,a determination can be made as to the accuracy of the user suppliedinformation. Thus, whenever an item of the user supplied information isindependently verified, then that item is unmarked. Alternatively, ifdiscrepancies arise between the user-supplied information and otherpublicly available information about the user, then the user may bealerted to these discrepancies and requested to confirm his/her initialresponses.

Referring now briefly to FIG. 3, this flowchart presents the steps auser performs when entering web site registration information into thefill-out forms to be submitted to registrar. Accordingly, in step 304the user determines whether to supply basic information (i.e., requestedby a substantial number of third party web sites 116) as described instep 308 or to supply expanded information (i.e., more extensiveinformation about the user so that, for example, registrar hassufficient user information to register the user at substantially allcooperating third party web sites 116). Note that at least in oneembodiment, the basic information supplied in step 308 (i.e., the user'sname, e-mail address, gender and date of birth) is also requested in theforms for expanded information in step 312. Thus, upon filling in atleast one field from the fill-out forms (step 316) presented in eitherstep 308 or 312 the present invention field checks the user's unput forsyntactically appropriate responses. Subsequently, in step 320, the userinputs a request to terminate entering information in the presentlypresented fill-out form(s) and in step 324 the user determines whetherto enter additional information in either the basic registrationinformation fill-out forms or the expanded information fill-out forms.If the user indicates that he/she desires to enter further registrationinformation, then step 304 is again performed. Alternatively, theflowchart returns to the invoking program (flowchart) with the usersupplied registration information.

FIGS. 4A and 4B present a flowchart for the steps performed when theuser accesses a present third party web site 116 cooperating withregistrar, and in the process of registering at the third party web sitethe user is automatically put in contact with the registrar web site 100so that registration information may be provided to registrar forregistering the user at the present third party web site as well asother third party web sites that the user may request. Accordingly,assuming the user uses a WWW browser 120 to access a third party website 116 as in step 404, the third party web site responds with a website home page (step 408) typically having a registration fill-out forminto which the user is requested to enter registration information. Notethat the user may or may not be registered at this third party web site.Thus, if the user is registered, then he/she may only need to enter auser ID and optionally a password in order to gain access to a desiredapplication at the third party web site. Further note that for differentthird party web sites 116, the user's identification (and optionally apassword) may be different due to constraints on user ID (and password)syntax being different at different third party web sites. Further, suchuser IDs at different web sites may be different because a user IDrequested by the user may already have been assigned to another user.

Subsequently, once the third party web site 116 has received a responsefrom the user, a determination is made as to whether the user isregistered at the web site (step 412). If the user is registered, thenno further processing related to the present invention is required.Alternatively, if the user is not registered at the third party website, then a response is transferred from the third party web site 116through the World Wide Web 104 to the user's WWW browser 120 providingthe user with the fill-out forms in which the user is requested to enterinformation for registering at the third party web site. Note that ifthe third party web site 116 is configured to accept user registrationinformation from the present invention, then at least one fill-out formrelated to registering at the third party web site 116 will requestinformation related to registering the user by using the presentinvention. In particular, the third party web site 116 may present theuser with a fill-out form requesting the user to enter a user ID andoptionally a password for the present invention (i.e., registrar) if theuser is registered at the registrar web site 100. Additionally, thepresented fill-out forms may request the user to indicate whether he/sheprefers to register at the third party web site 116 by using registrar.Thus, assuming the user desires to register at the third party web site116, a determination is made as to whether the user wishes to registerusing the present invention or register at the third party web sitewithout using the present invention (step 416). If the user chooses tonot use the present invention for registering at the third party website 116, then the user explicitly supplies registration information forthe present third party web site (step 420). Alternatively, if the userchooses to use registrar to register, then once the present third partyweb site 116 receives a response from the user indicating the choice touse registrar to register, in step 424, the present third party web sitesends a request to the registrar web site 100 for registering the userat the registrar web site 100. Subsequently, in step 428 the steps ofFIGS. 2A and 2B are performed for registering the user at the registrarweb site 100. Subsequently, after registering at the registrar web site100, in step 432, the user is automatically placed in contact with thepresent third party web site so that he/she submits a registrationfill-out form to this third party web site 116: (a) indicating that theuser's registration information may be obtained from the registrar website 100; and (b) providing a user ID (and optionally a password) forthe registrar web site 100 to be used as identification at the presentthird party web site. Following this, in step 436 the third party website 116 invokes the program corresponding to FIG. 5 to obtain theuser's registration data from the registrar web site 100. Lastly, uponverification by the third party web site 116 of the user's registrationdata, the user is granted access to the desired third party web siteand/or application (step 440).

In FIG. 5, a flowchart is presented of the registration datatransmission process from the registrar web site 100 to a third partyweb site 116. Accordingly, in step 504 the third party web site 116provides the registrar web site 100 with identification of the thirdparty web site, the user's registrar user ID and (any) registrarpassword. Further, in some instances, as will be described below, thethird party web site 116 also supplies the registrar web site 100 with areturn path to the user through the World Wide Web 104. Following this,in step 508, a determination is made by the registrar web site 100 as towhether the third party web site supplied information can beauthenticated. If not all third party web site information isauthenticated, then step 512 is encountered wherein a determination ismade as to whether to request that the third party web site to resendthe information of step 504. Note that such a determination may be madein one embodiment depending upon whether the third party web siteidentification is authenticated. That is, if the third party web siteidentification is authenticated, then a retry may be allowed. Otherwise,no retry may be allowed. Alternatively, referring again to step 508, ifall information transmitted from the third party web site 116 isauthenticated at the registrar web site 100, then step 516 isencountered. In this step, the program represented by FIGS. 6 isperformed for supplying the third party web site 116 with registrationinformation related to the user from the user registration informationdatabase 144.

Referring now to FIGS. 6A and 6B, the flowchart presented here providesthe steps for supplying a present third party web site 116 withregistration information from the registrar web site 100, assuming thatthe present third party web site 116 has requested such information andthat the request has been authenticated at the registrar web site 100.Accordingly, in step 604 the registrar web site 100 or, more precisely,a registrar application 128 performs the steps of FIG. 7 for retrievingthe user registration information requested by the present third partyweb site 116 from the user registration information database 144. Notethat a third party web site 116 may request various categories ofinformation from the registrar web site 100 related to the user. Inparticular, a third party web site may request: (a) basic information asdiscussed in step 308 of FIG. 3; (b) expanded information as discussedin step 312 of FIG. 3; (c) custom information, wherein selected fieldsfrom the basic and expanded information are provided; and (d)proprietary information wherein one or more additional user relatedinformation items may be provided wherein these items have been obtainedby the registrar web site 100 by, for example, enriching and verifyingthe registration information obtained from the user as in step 256 ofFIG. 2B.

Following step 604, step 608 is encountered wherein a registrationapplication 128 determines whether the present third party web site 116requesting user information (for a user attempting to register at thisthird party web site) requires that a user ID (and optionally password)be generated specifically for this third party web site. That is, thethird party web site 116 may require a user ID and/or password thatconforms with a format peculiar to the third party web site 116. Notethat to perform the step 608, in at least one embodiment of the presentinvention, information related to the requirements of the present thirdparty web site 116 are stored at the registrar web site 100. Inparticular, the registrar web site 100 may store a user informationrequest template for each third coordinating party web site 116 havingaccess to user information at the registrar web site 100 such that aregistrar application 128 (upon identifying a particular third party website 116) may access a related user information request template fordetermining what information may be required by this third party website.

If a user ID and optionally password need not be generated specificallyfor the requesting third party web site 116, then in step 612 the userinformation requested by the third party web site 116 is encrypted andin step 616 the encrypted information is sent to the third party website. Following this, in step 620 a registrar application 128 logs anentry or a record in the registrar access log database 152 indicatingthat registration information for the user has been transmitted to thepresent third party web site 116. Subsequently, in step 624 a registrarapplication 128 (or, more precisely, an instantiation thereof) waits foran acceptance response from the present third party web site 116 towhich the encrypted user information was sent. Note that the responsefrom the present third party web site may include a third party web sitespecific user ID (and optionally password) if the user was notpreviously registered at this third party web site. That is, the thirdparty web site may automatically generate at least a user ID if the userwas not previously registered at the web site. Alternatively, it may bethe case that the present third party web site uses the user's registrarregistration user ID and password for registering the user at the thirdparty web site 116. Note that in at least one embodiment forregistration processing at a third party web site 116, the use of theregistrar user ID does not create ambiguity in the identity of usersregistering at the third party web site. For example, a user seekingaccess to a cooperating third party web site may be required to indicatethat his/her user ID and/or password is a registrar generated user ID(and/or password) so that the third party web site can process theentered user identification differently from that of users who haveregistered without using the present invention. Subsequently, when anacceptance response from the requesting third party web site 116 isprovided to the registrar web site 100 (or, more precisely, a registrarapplication 128), this response is logged in the registrar access logdatabase 152 in step 628. Following this latter step, in step 632, adetermination is made as to whether the response from the present thirdparty web site 116 indicates that the user is now registered at thisthird party web site. If no such indication is provided, then in step636 a message is sent to the user at the user's WWW client node 108 thatregistrar cannot register the user at the present third party web siteto which the user has requested registration and access. Further, theregistrar application 128 performing step 636 may also supply the userwith a reason as to why the user cannot register through registrar atthe present party web site if such a reason was indicated by this thirdparty web site when the response of step 624 was received.

Alternatively, if in step 632 it is determined that the user isregistered at the present third party web site, then in step 640 theprogram corresponding to the flowchart of FIG. 8 is performed forstoring at least the user's ID (and optionally password) for the presentthird party web site at the registrar web site 100 (more precisely, inthe user registration information database 144) as will be discussedhereinbelow.

Referring again to step 608 of FIG. 6A, if a registrar application 128is required to generate a user ID (and optionally password) for thethird party web site 116, then step 644 is next performed wherein aregistrar application 128 generates a user ID (and optionally password)to be transmitted to the third party web site 116. Subsequently, thesequence of steps 648 through 668 are performed. Note that this sequenceof steps is substantially the same sequence of steps as steps 612through 632. However, the response from the present third party web sitelogged in step 664 may include an indication as to whether the usergenerated by the registrar application 128 is acceptable to the presentthird party web site 116.

Accordingly, continuing the discussion of FIGS. 6A and 6B from step 668,if the response from the present third party web site 116 indicates thatthe user is registered at the desired third party web site, then step672 is performed wherein the program corresponding to the flowchart ofFIG. 8 is again used to store the user's ID (and optionally password)for the present third party web site in the user registrationinformation database 144 (as in step 640). Alternatively, if in step 668it is determined that the user is not registered at the present thirdparty web site 116, then in step 676 a determination is made as towhether the generated user registration information (i.e., user ID andoptionally password) step 644 has been rejected by the present thirdparty web site. If so, then in step 680 a determination is made as towhether this rejection has occurred less than a predetermined number oftimes (i.e., the sequence of steps 644 through 668 have been iterativelyperformed less than a predetermined number of times in attempting toregister the user at the present third party web site). If the resultsof the test in step 680 is affirmative, then step 644 is againencountered for generating alternative user registration information forthe present third party web site. Note that it is an aspect of thepresent invention that, at least in one embodiment, such generationsproduce user IDs that are meaningful to the user and/or are related toother web site registration user IDs for the user. Thus, in oneembodiment of the present invention, the step 644 uses the user'sregistrar user ID as a "seed" from which to generate a user IDacceptable to the present third party web site 116. Moreover, note thatthe generation process of step 644 may use various heuristics and thirdparty web site constraints to generate acceptable user IDs.

Alternately, if the negative branch from step 676 is followed, then thethird party web site 116 may have rejected registering the user for anyof a number of reasons that may not be able to be alleviated in a timelyfashion so that the user can be registered at this third party web sitein a short amount of time. Accordingly, step 684 is encountered whereina message is transmitted to the user's WWW client node 108 indicatingthat registrar cannot currently register the user at the requested thirdparty web site 116. Further, note that if in step 680 it is determinedthat too many attempts have been made to generate acceptableregistration information for the third party web site, then step 684 isalso encountered.

The flowchart of FIGS. 6A and 6B is representative of the processingvariations within the scope of the present invention for supplying athird party web site with registration information. For instance, thoseskilled in the art will appreciate that steps 624 and 660 may have atimer associated with them whereby if there is no response from thethird party web site within a predetermined time period, then a defaultresponse is provided by a registrar application 128 so that one of thesteps 684 or 636 is performed as part of the processing when such atimer expires and subsequent steps in the flowchart are performed.Additionally, other steps may be inserted, for example, on the negativebranch from step 676 wherein these additional steps attempt to addressother anomalies indicated in the acceptance response received in step660. For example, if the third party web site 116 requests additionaluser information than what was provided in step 648, then if thisadditional information is in the user registration information database144 and the user has indicated that it is permissible to disseminatethis information, then the additional information may be transmitted tothe present third party web site 116. Also, in such a case, thetransmittal of this additional information is recorded in the registraraccess log database 152.

Referring now to FIG. 7, wherein the flowchart for a program is providedfor supplying, from the user registration information database 144, arequesting third party web site 116 with registration informationrelated to a particular user. Accordingly, in step 704 of FIG. 7, if theregistrar web site 100 has not been previously supplied with anindication as to what type of information is required by the requestingthird party web site, then a registrar application 128 constructs such arequest to be transmitted to the requesting third party web site andsubsequently the application may wait for a response from this thirdparty web site. Following step 704, in step 708 it is assumed that theregistrar web site 100 has been provided with an indication orspecification as to what information the requesting third party web sitedesires. Thus, the registrar application 128 performing step 704 may nowdetermine what registration information is to be transmitted to thisthird party web site. Note that at least in one embodiment of step 708,the user registration information requested may require validationaccording to the following criteria:

(1.1) The type and amount of registration information for a user thatthe user has indicated is available to be transmitted to a requestingthird party web site.

(1.2) The type and amount of information the requesting third party website 116 has contracted with the registrar web site 100 for transmittingregarding a particular user or category of users.

(1.3) The registration information available in the user registrationinformation database 144.

Thus, as discussed with respect to step 604 of FIG. 6A, either basic,expanded, custom or proprietary registration information related to auser is transmitted to the requesting third party web site in step 736.

FIG. 8 presents a flowchart for storing, in the user registrationinformation database 144, a user's ID and/or password for a third partyweb site 116 to which the user is registered using registrar. Moreprecisely, the user ID and/or password for such a third party web siteis stored via the steps of FIG. 8 if this information is different fromthe user's registrar user ID and/or password. That is, it is believedthat for many third party web sites 116, the registrar user ID andpassword for users registered at the registrar web site 100 will beidentical to the user's user ID and password at third party web sites.Note that there are significant advantages to third party web sites 116using, for each registered user, the user's registrar user ID andpassword (or, some other user ID and password in common with other thirdparty web sites to which the user is registered). For instance, a useris required to remember fewer user IDs and passwords associated with websites and the web sites providing this convenience may have a highervolume of users accessing the web site due to the greater ease ofaccess.

Regarding the steps of FIG. 8, in step 800 a determination is made as towhether the user has been provided with a user ID (optionally password)for the third party web site 116 (to which the user is attempting toregister) that is different from the user's registrar user ID and/orpassword. If not, then there is nothing additional to store at theregistrar web site 100 and the flowchart ends. Alternatively, if thedecision of step 800 results in a positive answer, then step 804 isperformed wherein the user's specific user ID and optionally passwordfor this third party web site is stored with other user registrationinformation in the user registration information database 144. Note thefollowing advantages accrue by storing user registration information atthe registrar web site: (a) each user has the convenience of off-sitestorage backup for each such third party web site to which the user isregistered and (b) depending on the registration process at the thirdparty web site, it may be expedient for such a web site (at leasttemporarily) to automatically contact the registrar web site 100 forretrieving, for example, the user's third party web site specific userID upon subsequent user accesses to the third party web site.

Following step 804, in step 808 a determination is made as to whetherthe third party web site has indicated that it will initiate requests asin (b) immediately above. If so, then no further processing needs to beaccomplished here in that the user may enter his/her user registrar website 100 user ID (and optionally password) when accessing the thirdparty web site. Alternatively, if step 808 yields a negative answer thenstep 812 is performed wherein the registrar web site 100 sends a messageto the user at the user's WWW client node 108 providing the user withthe ID (and optionally password) for the third party web site.

In an alternative embodiment of the present invention, a registrarregistration module 156 may be provided at the user's WWW client node108. This module (whether incorporated into the WWW browser 120 orexternal to the browser and communicating with the browser through, forexample, a browser 120 port) may store locally at the client node 108registration information for accessing third party web sites 116 towhich the user has registered using the present invention. In FIGS.9-13, flowcharts are provided for programs illustrating the processingof this alternative embodiment of the present invention.

In FIG. 9, a flowchart is presented of the program for registering at athird party web site 116 when the module 156 is installed on the user'sclient node 108.

Describing now the steps of FIG. 9, in step 904 the user sends a requestto access a third party web site 116 via the user's WWW browser 120.Subsequently, upon receiving the request, the accessed third party website 116 responds with a home page having a registration fill-out form(step 908). Assuming that the registration fill-out form allows the userto indicate that user registration information may be obtained locallyat the client node 108, in step 912 the user indicates on the fill-outform that he/she desires to register at the third party web site andthat his/her registration information can be retrieved using theregistrar registration module 156 residing on the user's client node108. Further note that the user may be required to activate or alert themodule 156 so that this module can supply the appropriate userregistration information to be communicated to the third party web site116. Also note that the home page from the third party web site 116 mayindicate the type of information required to register the user and thisinformation may be used either manually or automatically for determiningthe user registration information stored on the user's client node 108that will be transmitted to the third party web site. Subsequently, instep 916 the user specifies that the registration fill-out form is to besubmitted to the third party web site. Accordingly, the WWW browser 120communicates with the registrar registration module 156 to supply theregistration information to the third party web site. That is, theprocessing performed here includes the steps of FIG. 10 which aredescribed herein below. Subsequently, in step 920 a message is sent fromthe registration module 156 to the registrar web site 100 indicatingthat the user has registered at the third party web site andadditionally supplying the registrar web site 100 with any user ID andpassword specific to the third party web site. Note that by sending thisinformation as well as, for example, a copy of substantially all of theuser's registration information stored locally to the registrar web site100, the user is provided with an automatic off-site backup of his/herregistration information. Additionally, the user may be provided withother advantages by providing his/her user registration information tothe registrar web site 100. In particular, the registrar web site 100may enrich the user's registration information with publicly availableinformation on the user and alert the user to discrepancies between theuser information and various publicly available records on the user.

Referring now to the flowchart of FIG. 10, this flowchart describes thesteps performed when supplying a third party web site 116 withregistration information retained by the registrar registration module156 on the user's node. In step 1004, the steps of the flowchart of FIG.7 are performed for retrieving the registration information requested bythe third party web site. Subsequently, in step 1008 the registrarregistration module 156 packages the accessed registration informationfor the third party web site together with the user's registrar ID (andoptionally password) for transmittal to the third party web site.Subsequently, in step 1016 the registration information packagedtogether in step 1008 is encrypted so that in step 1020 this encryptedinformation may be sent securely to the third party web site via theWorld Wide Web 104. Following this, in step 1024 the module 156 logs anentry into a local log on the client node 108 indicating whatregistration information was sent to the third party web site.Subsequently, in step 1028 a process may be instantiated to wait for anacceptance response from the third party web site so that when such aresponse is obtained it may be logged locally at the client node 108 instep 1032.

In one embodiment of the present invention the user may configure theregistrar registration module 156 to log all activities with third partyweb sites 116 and provide the records of this log to the registrar website 100. This allows the registrar web site 100 or personnel thatmaintain the registrar web site 100 to analyze user activities on theWorld Wide Web 104. Such analysis may be useful to both registrar usersand third party web site personnel in that, given a user's World WideWeb 104 activity, the registrar web site 100 may suggest additionalthird party web sites 116 of which the user may not be aware. Further,by analyzing the user access logs of registrar users, the registrar website 100 may provide statistics to the third party web sites 116 as tothe number and types of users accessing their respective web sites.

FIGS. 11A and 11B present a flowchart for the steps performed by thepresent invention when the user changes his/her registrar registrationinformation. That is, the flowchart of FIGS. 11 encompasses both thearchitecture or embodiment of the present invention wherein the user'sregistration information is stored substantially only at the registrarweb site 100, and also the architecture or embodiment wherein the user'sregistrar information is also stored at the user's client node 108.Accordingly, in step 1104 a determination is made as to where the user'sregistration information is stored. Note that this step 1104 is unlikelyto be explicitly performed by either the present invention or the user.Instead, the embodiment of the present invention determines which of thepaths from this step to follow (i.e., if module 156 exists, then the"USER NODE" branch is followed; otherwise, the "REGISTRAR WEB SITE ONLY"branch is followed). Accordingly, assuming that the present invention isembodied such that the user's registration information is stored at theweb site 100 only, then step 1108 is encountered wherein the useraccesses the registrar web site 100 from his/her WWW client node 108 byentering his/her user ID and optionally password. Subsequently, in step1112 the registrar web site 100 responds with a web page having a numberof options related to the user's registration information and registrarweb site 100 processing of this information. Note that such optionsinclude a request by the user to modify the user's registrationinformation stored at the registrar web site. Additionally, otheroptions may be also provided to the user including: (a) an option forrequesting to be no longer affiliated with the registrar web site 100and have all the user's registration information deleted; (b) an optionfor requesting to examine all information regarding the user stored atthe registrar web site 100, including all information the registrar website has obtained from publicly available sources; (c) a request forprocedures and/or addresses to contact publicly available databases thatregistrar has accessed obtaining incorrect user information; and (d)third party web sites 116 that are providing information for a limitedperiod of time and for which the user may be interested. Following step1112, in step 1116 the user enters new information into an appropriatefill-out form received at the user's WWW client node 108 from theregistrar web site 100. Note that this form is likely to be in a pagedifferent from the page of options described in step 1112. That is, uponsubmission of the page of options, the registrar web site 100 respondswith a new page(s) having fill-out forms with the presently stored userregistration information presented in the forms so that the user maychange any of the fields on this page(s).

Note that in at least one embodiment of the present invention, the useris allowed to change his/her registrar user ID and/or password. However,it may be the case that when a user changes his/her registrar user ID,that the new requested user ID has already been assigned to anotherregistrar user. Thus, the registrar web site 100 may respond with arequest for further information (such as a request for a different userID from the user) wherein when the user submits the additionalinformation, the registrar web site 100 again checks to determine if theuser is uniquely identifiable. Note that the loop of steps 1120 and 1124are provided to represent the iterative process described here ofchanging the user's user ID. Further note that in some embodiments ofthe present invention, the registrar web site 100 may respond withalternative variations for a new user ID so that the user is not left toguess at a registrar user ID that is acceptable for uniquely identifyingthe user.

Returning now to step 1104, if the user's registration information isstored locally at the user's client node 108, then step 1128 isperformed instead of the steps 1108-1124. However, for simplicity, adiscussion of the processing performed in step 1128 is not described indetail here. Instead, a detailed discussion of this step is provided byFIGS. 12 and the discussion of FIGS. 12 hereinbelow for changing theregistration information at the user's client node 108 and fortransmitting the changes to the registrar web site 100.

Regardless of the branch of processing taken from step 1104, eventuallystep 1132 and the subsequent steps of FIG. 11B are encountered whereinthe present invention updates or alerts third party web sites havingpreviously received user registration information that this informationmay be outdated. Thus, the steps 1132-1140 are performed so that theregistration information provided to such third party web sites via thepresent invention is consistent with the newly supplied userregistration information. However, in at least one embodiment of thepresent invention, prior to providing any newly entered userregistration information to the third party web sites, such informationmay be compared or correlated with publicly available informationregarding the user that is, for example, accessible via certain thirdparty web sites 116. Further, the user may request his/her newly enteredregistration information by supplied to only selected web sites to whichthe user is registered, or alternatively, the user may request that thenewly entered registration information be supplied to all web sites towhich the user is registered.

FIG. 12 presents a flowchart of the steps performed when the registrarregistration module 156 is provided at the client node 108 and the userenters registration information into this module. Note that the steps ofthis flowchart may be performed when the user is entering registrationinformation for registering the user with registrar, or when modifyingregistration information already supplied to registrar. Accordingly, instep 1204 the user requests activation of the registrar registrationmodule 156 on the user's client node 108 for entering information thatwill subsequently be used for registering substantially automaticallycooperating at third party web sites 116 requested by the user.Subsequently, in step 1208 the registrar registration module 156 on theuser's client node 108 presents the user with one or more fill-out formsfor the user to provide new registration information. Following this, instep 1212 a determination is made as to whether the user requests toobtain a registrar user ID. If so, then in step 1216 the programcorresponding to the flowchart of FIG. 13 is performed to provide theuser with a valid registrar user ID and optionally password.Subsequently, in step 1220 a determination is made as to whether theprogram of FIG. 13 returns a valid registrar user ID. If so, then step1224 is performed wherein the new user's registrar ID is stored on theuser's node 108 for a subsequent transmittal to a third party web siteduring a registration process at a third party web site that accepts theregistrar user ID as the web site's ID. Subsequently, regardless of thepath taken from step 1220, step 1228 is encountered wherein adetermination is made as to whether the user desires to enter furtheruser registration information.

If the user desires to enter further information, then step 1212 isagain encountered and a determination is made once again as to whetherthe user requests to obtain a registrar user ID. However, it isimportant to note that the steps provided in this flowchart are only anindication of the processing provided by the registrar registrationmodule 156 and the user's browser. In particular, since the userinterfaces typically used by World Wide Web browsers allow a user toselect the fill-out form fields to modify, the positive branch from step1212 is taken only when the user enters information in a fill-out formfield indicating that a registrar user ID is requested. Similarly, thenegative branch from step 1212 is taken whenever user information isentered into other fill-out form fields unrelated to obtaining aregistrar user ID.

Accordingly, if the user desires to enter other information than thatrequired to obtain a registrar user ID, then from step 1212, step 1232is encountered wherein the registrar registration module 156 explicitlyrequests the user's registrar registration user ID (and optionallypassword). Subsequently, in step 1236, assuming the user enters aregistrar user ID, a determination is made as to whether the registraruser ID is valid. Note that this determination is initially made locallyat the user's client node 108 without contacting the registrar web site100. However, in one embodiment of the present invention, it is anoption that if the registrar user ID entered is not found in the clientnode 108, then the registrar registration module 156 may inquire of theuser as to whether he/she desires the registrar web site 100 to beinterrogated for the registrar user ID and password and, if found,download the user's registration information to the user's client node108. If no valid registrar user ID is determined in step 1236, then theprogram ends in step 1240. Alternatively, if a valid registrar user IDis obtained, then in step 1244 a determination is made as to whether theuser requests to exit the present program and thereby stop supplyingregistration information. Note that this step is similar to step 1212 inthat if the user continues to enter registration information in fill-outform fields, then the negative branch from this step is followed and,alternatively, if the user, for example, activates an exit button on theuser interface, then the positive branch from step 1244 will befollowed. Accordingly, if the negative branch is followed, then in step1248 the program of FIG. 3 is performed for obtaining new userregistration information and, subsequently, step 1212 is encountered(or, more precisely, the user interface is provided that allows the userto request a registrar user ID).

Alternatively, if the positive branch is taken from step 1244, then step1252 is encountered wherein the registrar registration module 156transmits (or schedules the transmission of) any newly entered userregistration information that the user desires to be transmitted to theregistrar web site 100 for backup storage. Thus, in one embodiment ofthe present invention, the step 1252 provides the user with the optionto discard the registration information provided in step 1248 aboveinstead of transmitting this information to the registrar web site 100.

In FIG. 13, a flowchart is presented of the program for obtaining aregistrar user ID and optionally password for the embodiment of thepresent invention wherein the registrar registration module 156 retainsthe user's registrar user ID (and optionally password) for automaticallyproviding to third party web sites at which the user requestsregistration using the present invention. Accordingly, in step 1308 theregistrar registration module 156 requests the user to select aregistrar user ID and optionally a password that can be used to accessthe user's registration information at both the user's client node 108and at the registrar web site 100. Assuming that the user enters a userID and optionally password in step 1308, in step 1312 the registrarregistration module 156 transmits the user selected ID and optionallypassword to the registrar web site 100. Subsequently, in step 1316 adetermination is made by the registrar application 128 as to whether theuser's selected user ID and optionally password are acceptable to theregistrar web site. That is, a registrar application 128 accesses theuser registration information database 144 to determine if the selecteduser ID is sufficiently unique. Note that other steps may be performedbetween steps 1308 and 1312. For example, the syntax for user IDs andoptionally passwords may be checked at the module 156 prior totransmitting the user's selected registration information to theregistrar web site 100.

Continuing with step 1316, a determination is made at the registrar website 100 as to whether the user's selected user ID and optionallypassword are acceptable to registrar. If so, then in step 1320 aregistration application 128 stores the user's ID and optionallypassword in the user registration information database 144. Note thatsince it is unlikely that any further information related to the presentuser is stored at the registrar web site, the process of storing theuser's user ID and optionally password includes creating a new record inthe database 144 and marking all remaining fields related toregistration information for this user to indicate that these fields areas yet not valid. Following this, in step 1324 a registrar application128 transmits a message to the user's WWW browser 120 indicating thatthe user's selected user ID and optionally password is acceptable toregistrar.

Alternatively, if the negative path is taken from step 1316, then step1336 is encountered wherein a registrar application 128 attempts togenerate an acceptable user ID and optionally password as a substitutefor the user's proposed user ID (and optionally password). Note that ingenerating alternative registration information, the registrarapplication 128 may use the user supplied information as the basis or"seed" for generating an acceptable user ID (and optionally password) tobe transmitted back to the user. Accordingly, in step 1340, once theuser is presented with the newly generated registration information onthe user's client node 108, the registrar registration module 156provides the user with the option to accept or reject the generatedinformation. If the user accepts the generated registration information,then the flowchart ends. Alternatively, if the user rejects thisinformation, then in step 1348 a further determination is made by themodule 156 as to whether the user enters a new user ID (and optionallypassword) as an alternative to the generated registration information.If such new user registration information is provided, then step 1312and steps thereafter are again performed in attempting to provide aregistrar user ID (and optionally password) to the user. Alternatively,if the user indicates in step 1348 that no further proposed candidatesfor a user ID (and optionally password) will be forthcoming, then theflowchart ends without an acceptable registrar user ID being obtained.

The foregoing discussion of the invention has been presented forpurposes of illustration and description. Further, the description isnot intended to limit the invention to the form disclosed herein.Subsequently, variation and modification commensurate with the aboveteachings, within the skill and knowledge of the relevant art, arewithin the scope of the present invention. The embodiments describedhereinabove are further intended to explain the best mode presentlyknown of practicing the invention and to enable others skilled in theart to utilize the invention as such, or in other embodiments, and withthe various modifications required by their particular application oruses of the invention. It is intended that the appended claims beconstrued to include alternative embodiments to the extent permitted bythe prior art.

What is claimed is:
 1. A method for registering a user at a plurality ofuser requested nodes of a communications network wherein nodes of thenetwork are identified using an Internet addressing scheme,comprising:first storing registration information related to the user ina first data store on a first node of said network, said registrationinformation including demographic information regarding the user that isuseful by web site operators in monitoring web site usage; secondstoring said registration information in a second store on a second nodeof said network, said second node being different from said first node;providing the user with a user identification code permitting access tosaid registration information in at least one of said first data storeon said first node and said second store on said second node; supplyingto at least one requested node of said plurality of requested nodes: (a)said user identification code for registering the user at said at leastone requested node, and (b) said registration information transmittedfrom one of said first data store on said first node and said secondstore on said second node for registering the user at said at least onerequested node, wherein the user can automatically provide saidregistration information, including said demographic information usefulfor monitoring web site usage, to said at least one requested node.
 2. Amethod as claimed in claim 1, wherein said first node is a client nodeand said second is a server node.
 3. A method as claimed in claim 1,wherein said communications network utilizes an internet protocol.
 4. Amethod as claimed in claim 1, further including a step of providing amodification to said registration material from said first store to thesecond store.
 5. A method as claimed in claim 4, wherein said step ofproviding includes retaining said modification in said first and secondstores, wherein said modification is transmitted to said at least onerequested node in said step of supplying.
 6. A method as claimed inclaim 1, wherein said first step of storing includes inputting saidregistration information by the user.
 7. A method as claimed in claim 1,wherein said step of second storing includes transmitting saidregistration information from said first node to said second node usingsaid communications network.
 8. A method as claimed in claim 1, whereinsaid step of supplying includes:inputting user identification from saidfirst node; transmitting said user identification to said second node;and using said user identification at said second node for determiningsaid user identification code.
 9. A method as claimed in claim 1,wherein said step of supplying includes requesting, by said at least onerequested node, said registration information from said second node. 10.A method for registering a user at a plurality of user requested nodesof a communications network wherein nodes of the network are identifiedusing an internet addressing scheme, comprising:manually inputtingregistration information related to the user at a first node of saidnetwork, said registration information including demographic informationregarding the user that is useful by web site operators in monitoringweb site usage; transmitting said registration information from saidfirst node to a second node of said network; providing the user with arequest concerning access to said registration information at saidsecond node; transmitting a communication from said first node regardingsaid registration information in response to said request; supplyingsaid registration information from said second node to at least onerequested node of said plurality of requested nodes upon receipt of saidcommunication, wherein the user can automatically provide saidregistration information, including said demographic information usefulfor monitoring web site usage, to said at least one requested node. 11.An apparatus for registering a user at a plurality of user requestednodes of a communications network wherein each node of the network isidentified using an internet addressing scheme, comprising:means forproviding registration information related to the user on a first nodeof said network; means for transferring said user information to saidmeans for providing from a second node of said network; means fortransmitting a user identifying code from said first node to said secondnode, said user identifying code related to said registrationinformation; means for registering the user on at least one requestednode of said plurality of requested nodes by transmitting said useridentification code from said second node to said at least one requestednode; means for determining, at said at least one requested node, saiduser registration information is provided by said first node; means forrequesting, by said at least one requested node, said registrationinformation from said first node by supplying said first node withinformation identifying said user identification code.
 12. A method foruse in transmitting registration information between nodes of acommunication network, wherein nodes of the network are identified usingan internet addressing scheme, comprising the steps of:receiving, at afirst node of said network, user registration information regarding aninternet user from a second node of said network associated with theinternet user, said registration information including demographicinformation regarding the user that is useful by web site operators formonitoring web site usage; storing said user registration information atsaid first node; receiving, at said first node, a communication fromsaid second node regarding re-transmission of said user registrationfrom said first node to a third node of said network; andre-transmitting, based on said communication from said second node, saiduser registration information from said first node to said third node,wherein the user can automatically provide said registrationinformation, including said demographic information useful formonitoring web site usage, to said third node.
 13. The method of claim12, wherein said step of receiving a communication comprises receivingpermission from said user to disseminate said registration informationincluding said demographic information.
 14. A method for use intransmitting registration information between nodes of a communicationssystem, wherein nodes of the communications system are identified usingan internet addressing scheme, comprising the steps of:providing anetwork structure for use in conducting communications between a firstnode associated with a network user, a second node wherein registrationinformation regarding said network user is stored and a third node, saidregistration information including demographic information regarding theuser that is useful by web site operators for monitoring web site usage;first conveying, using said network structure, a request from said thirdnode regarding access to information including said registrationinformation; second conveying, using said network structure, acommunication from said first node regarding access to said registrationinformation stored at said second node; and third conveying, using saidnetwork structure and based on said communication from said first node,a communication including said registration information from said secondnode to said third node, wherein the user can automatically provide saidregistration information, including said demographic information usefulfor monitoring web site usage, to said at least one requested node.